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Planning and Administration 

Responsibility for I/O device microcode and drivers v/as transferred to Communication Software as 
a result of the reorganization announced by Bill Lynch in his 12 February memo entitled "Systems 
Software Section Reorganization". Tlie group has been renamed Communicadon and I/O Software 
(CIOS) and now includes Pitts Jarvis, John Ng, and Alan PYeier, who is scheduled to report on 15 
March. Yogen Dalai and Jim White assumed project leadership responsibility for OIS 
Communication and IOCS, respectively. 

CIOS now has a large number of vacant slots to fill: two in OIS Communication and several in the 
IOCS area. Jim, Yogen, and oUiers in the group have begun actively seeking out and interviewing 
candidates. 1lie need for OISCP personnel is aggravated by Jim's new IOCS responsibilities, llie 
current IOCS manpower shortage (along with uncertainty about device availability) severely limits 
the number of I/O devices for which microcode and device drivers can be generated in the Teak 
time-frame. David Liddlc has given guidance diat the UTLF, Model 31, Htherncl, and SA4000 
must be supported in Teak. With help from Bill Kennedy, Jim has been tasked to develop a plan 
for the implementation of those devices, based upon device availability, required level of effort, and 
the current Teak release dale. Steps will then be taken by SDD to supply the necessary manpower. 

Jim submitted to Bill Lynch on 2 February the first drafi of Communication Software's 1979 work 
plan. A prioritized task list, prepared as preparation for the 23 January Pilot Hearings, is filed on 
(Iri.s]<\Vhite>Conuu'rasks.Biav(). Jim will assume responsibility for the IOCS work plan, whose first 
draft was submitted by Bill Kennedy on 7 I'cbruaiy. Both docmucnts will be refined and 
rereleascd within the next week. 

OIS Communication 

Alto Software 

Hal Murray augmented the Pup Internetwork Router and associated servers to support the new boot 
file distribution technique developed by Dave Hoggs (PARC). Hal also consulted with Mob Bell 
and John Becley (ASD) regarding die Internetwork Router's use in upcoming ASD probes in 
Sweden. Hal and Yogen Dalai continue to serve as their Mesa consultants, Hal also delivered his 
Mesa Press printing software to Charlie Levy to enable Star prototypes lo print files on Dovers. 

Hal converted the Pup and I'lP Packages, and partially converted the Pup Internetwork Router, to 
run under Mesa 5.0. The Mesa Group and CIOS have agreed to include Pup and PTP, upon 
which a large user community now depends, as part of this and subsequent Mesa releases, 'Ibward 
this end, bt)th software packages are now undergoing pre-alpha testing. Although minor problems 
remain to be straightened out, Yogen Dalai converted the Alto version of the OIS Comiuunication 
Package (OISCP) to run under Mesa 5.0, which has improved the pcrft)rmance of this software. 
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Jim White consulted with Jay Israel (PARC) regarding his prp-bascd Juniper mail server, with 
Mike Schroeder and Roy Levin (PARC) regai"ding proposed minor changes to Fl'P for the next 
Laurel release, with Steven Abraham regarding use of TIP for dumping and loading the Star file 
system to and from an IPS, and with Jerry Morrison and Bruce Malasky regarding what proved to 
be an FlP-related Brownie bug. Hal consulted with Tony Frederico (WRC) regarding the use of 
mini- Ethernets in copiers. 

DO Software 

Wd\ Murray and Yogen Dalai began reorganization for Pilot 3.0 of the Pup and CIS 
Conununication Packages. Yogen also measured the performance of the existing Pilot 2.0 Pup and 
OlSCP software. This data will serve as a baseline for comparison with subsequent versions of the 
software, beginning with Pilot 3.0. Using the officially released microcode, witli tlie display on, and 
sending to an Alto, the following net throughputs in kilobits per second were measured: 





Checksums On 


Checksums Off 




Socket Stream 


Socket Stream 


Pup 


102 74 


409 144 


OISCP 


81 45 


210 87 



With Roy Ogus, ILal continued to exercise the DO Xerox Wire board. Widi the display task 
completely disabled, most packets arc transmitted and received successfully. In the absence of 
scatter/gather and buffer dispatch index capabilities, however, things work much better. This fiict 
raises tlic important question of whether these fcaliu'es should be mandatory for all OlS processors, 
made optional, or abandoned entirely. Yogen, Hal, Roy, and Dave Boggs are exploring this 
question. 

Hal has written a DO Hthernet driver that uses Roy Ogus's lOCR microcode, and has installed it in 
a DO version of the Pup Internetwork Router. 

Remote Procedure Call Package 

Product Software successfully integrated RPCP wiUi Star on 1 February. RPCP's Mesa data 
structure serialization and deserialization primitives are now in use by Star filing and printing 
software. Jim White worked only briefly on the RPCP Functional Specification. This effort is 
suffering because of tiie demands placed on Jim's time by planning and, more recently, IOCS. 

Gateway Functions 

RS232C Hardware 

A new i'ROM has been installed in ClOS' DO I^M, enabling the testing of synchronous microcode 
on the DO to proceed. 

Hans Scharmann released an updated version of the MIOC Requirements Specification, which fairly 
accurately reflects the input of Victor Schwartz and Bill Daniclson. 

RS232C Microcode 

Bill Daniclson completed initial (loop-back) testing of both asynchronous and byte-synchronous 
RS232C microcode variants, which he integrated with the 2.1b microcode release. Bill also v/rote 
Mesa code that simulates those variants, enabling testing of Gateway software to proceed on the 
Alto. The testing of' bit-synchronous microcode has been deferred as a result of the Teak Hearings. 

Bill Daniclson replied to Bill Lynch's request for a sunnnary of resources required by the RS232C 
microcode, which consumes 1.5 pages, 2 tasks, 32 registei"S, and 5 limeis. Bill and Victor Schwartz 
met with Carol llankins befi)rc her departure, and Carol promised to include these resource 
requirements in her farewell memo. Victor also ran an experiment for Bill Lynch to compare 
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processor bandwidth utilization for CRC computation in Mesa and microcode. 

RS232C Channel 

On 16 February, Victor Schwartz submitted to Project Coordination for approval a draft of the 
RS232C chapter of the Pilot 3.0 Functional Specification. It redects a great deal of interchange with 
Leo Nikora, Bob Bell, and Bob Beelcy (ASD). 

Both the Alto and DO (Alto-emulation) versions of the RS232C Channel have been upgraded to 
conform to this interface, and have successfully run the appropriately-upgraded loop-back test in 
both asynchronous and byte-synchronous modes. The Channel software required to support the bit- 
synchronous mode of operation is coded but untested. 

Note that, consistent with the outcome of tlie Teak Hearings, byte-synchronous support (for 
example, for the System 6) is receiving priority over bit-synchronous support (for example, for OlS 
communication via phone lines). 

BSC Driver and Framer 

Sarah- Ann Bishop completed the receive function of the Framer and Driver on 12 February, and 
Larry Garlick and Sarah-Ann began debugging it via the Xerox 800 on 16 Febmary. 
Documentation of the BSC driver has been deferred to accelerate testing. 

Gateway Streams 

Larry Garlick and Sarah-Ann Bishop successfully transmitted files, in both directions, between an 
Alto and the Xerox 800 tape system. Gateway client software outputs the incoming file via the 
Mesa typescript, with no attempt at format conversion. 

Text was successfully transferred from an Alto to the IBM System 6 diskette via a Gateway stream. 
New versions of the RS232C byte-synchronous microcode simulator and RS232C Channel software 
were provided by Bill Daniclson and Victor. Sarah-Ann's BSC driver, used primarily with the 
Xerox 800, was slightly modified to handle the I.'-BCDIC code set. Other Gateway softwai'e was 
altered to include the session and protocol descriptors that define communication with the System 6. 
'Jhe demonstration program, a Gateway client, was augmented to Include the conversion software 
required to transfonn a Bravo file into an EBCDIC System 6 file. Implementation of other filters 
of tills sort has been identified as a reasonable assigimicnt for a summer student. 

Larry implemented an experimental TFY-simuUition Gateway stream, which is able to dial MAXCl 
and support an interactive session. Besides validating the soundness of the current Gateway 
architecture, the experiment reidcntified certain pcribrmancc-rclatcd changes that will eventually be 
required for non-frame-oiiented protocols. 

Miscellaneous 

Tom Morsley agreed to include Gateway software among the code he coordinates for Teak. 

Larry pioduced a new version of tlie Gateway Functional Specification, which is filed on 
|lKiSJ<GarIick>Gatevvay>func2.0>GateFunc.bravo. 

Integration of the RS232C Manager and OIS Transporter into Pilot has been rescheduled for March 
and April to better match the OlSCB schedule. 

A modular phone plug was installed in Sarah-Ami's office on 31 January. 

input/Output Control System 

The Architecture Board created an 10 Working Group consisting of Pitts Jarvis, Dave iU^dcll, I'd 
Talt, and .lim White (chairman) to make recommendations regarding the nature of the I'rincOps 
I/O specification. At its 22 P'ebruary meeting, the Board accepted in principle the group's 
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rcconiiiKMidation that llic specification be at tlic Mesa procedural, rather tlian the microcode, level. 
One implication of that decision is that the OIS virtual machine is implemented not only from 
hardware and microcode, but also from Mesa softwaie. Jim White's 20 February memo entitled 
"Status Report of 10 Working Gioup" overviews the group's position. 

Pitts .larvis continued work on the RDC software and helped install an RDC on a Palo Alto DO 
EM. "^I'hc RDC attached to Bags now works, and we have a spare RDC and another SA4G00 on 
order. 

With help from Pitts, John Ng worked on the interim floppy disk controller design while coming up 
to speed on Mesa, the DO, and the FDC hardware design specification. This woik included a trip 
to El Segundo to meet with Jack Cameron, Ruben Loshak, and Jim Katsiroumbas. 

Problems 

Tlic IOCS project is desparatcly short of manpower. It is unlikely that CIOS can implemented the 
device microcode and drivers required by Teak without additional assistance from elsewhere within 
SDD. 

The Dover that serves Building 34, along with the Alto that supports it, arc scheduled for removal 
soon. Only prompt action by SD Support will avoid leaving the approximately ten SDDers in that 
building without printing services. 

The severe shortage of DO control store continues to threaten to change the architecture of the 
RS232C channel/microcode interface. Bill f^anielson and Victor Sclnvarl/. will meet with Bill Lynch 
to make certain he is fully aware of all the tradeoffs involved and the extent of our studies to date. 
Also, no progress has Ijeen made on implementing microcode overlays. 

The arc welder in the basement of Building 34 continues to render many of our Altos and our only 
DO EM useless whenever it is in use. 

CIOS is unhappy with Star's current model of communication with foreign devices. Gateway 
Functions discussed this subject with Dave Smith on 30 January, but further discussion is necessary. 
Both groups seem hard-pressed to find time to pursue this issue. 

Tlic MIOC Requireniculs Specification contains a disclaimer about what will be built in hardware 
and what will be imjileiucntcd in microcode. It is unclear, therefore, how SDD can track and/or 
control what hardware is actually produced. 

llie sketchiness of the protocol documentation for both the Xerox 800 and the IBM System 6 have 
resulted in a number of surprises during testing. 

c: SDD/SS/CIOS 



